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This  paper  describes  a  language  for  programming  a  microprocessor  which  combines  the 
features  of  assembly  languages  wi.h  those  of  higher  level  languages.  The  goal  of  the 
language  design  was  to  p'ovide  a  convenient  microprogramming  language  for  the  MLP-900 
microprocessor  project  at  USC/lnformation  Sciences  Institute. 

The  goal  was  accomplished  by  designing  a  language  with  careful  consideration  of  the 
hardware  instruction  set.  The  language  was  also  constrained  not  to  implicitly  affect  the 
machine  at  runtime.  The  considerations  provided  freedom  and  low-level  control  for  the 
programmer.  The  flexibility  needed  by  the  compiler  to  allow  for  higher-level  language 
forms  was  also  provided  by  allowing  the  language  to  produce  several  microinstructions  for 
each  language  statement. 
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Abstract 

This  paper  describes  a  language,  for  programming 
a  microprocessor,  which  combines  the  features  of 
assembly  languages  with  those  of  higher  ievel  lan¬ 
guages  The  goal  of  the  language  design  was  to 
provide  a  convenient  microprogramming  language 
oi  the  MLP-900  microprocessor  project  at  the  USC/ 
Information  Sciences  Institute 

This  goal  was  accomplished  by  designing  a  lan¬ 
guage  with  careful  consideration  of  the  hardware 
instruction  set  Additionally,  the  language  was  con¬ 
strained  not  to  implicitly  affect  the  machine  state  at 


runtime  These  considerations  provided  freer  jm  and 
low-level  control  for  the  programmer  The  compiler 
needed  some  flexibility  to  allow  for  higher  level 
language  forms  This  flexibility  was  provided  by 
allowing  the  language  to  produce  several  microin 
structions  for  each  language  statement 

This  project  is  sponsored  by  the  Advanced  Re¬ 
search  Projects  Agency  This  work  is  directed  toward 
an  ARPANET -based  sharable  resource  as  a  means  of 
expionr  d  computer  architecture,  language  develop¬ 
ment  and  special  purpose  processor  design,  all  of 
which  are  of  particular  relevance  to  DOD  selection 
and  use  of  computer  equipment. 
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A  MICROPROGRAMMING  LANGUAGE 
FOR  THE  MLP-900 


Donald  R.  Oeslreicher 


Introduction 

Microprogrammed  computers  are  typically 
characterized  by  small  control  memories  for 
the  storage  of  microprogrammed  routines 
These  routines  are  used  to  implement  the 
firmware  instruction  set  for  the  target  com¬ 
puter.  The  storage  requirements  and  target 
computer  instruction  execution  time  consid¬ 
erations  bring  pressure  on  the  micropro¬ 
grammer  to  make  optimal  use  of  the  micro¬ 
processor  and  associated  control  memory. 

These  conditions  make  microprogram¬ 
ming  language  designers  and/or  program¬ 
mers  tend  towards  a  one-to-one  correspon¬ 
dence  between  language  statements  and 
actual  hardware  microinstructions.  As  a  re¬ 
sult  microprogramming  languages  often 
look  like  classical  assembly  languages  1 7,2). 
This  paper  reports  an  effort  to  provide  the 
convenience  and  readability  of  a  higher- 
level  language,  without  preempting  the 
flexibility  and  machine  state  control  availa¬ 
ble  in  assembly  code  (3). 

General  Purpose  Microprogramming  Lan¬ 
guage  (GPM)  is  the  primary  language  for 
the  MLP-900  microprogramming  project  at 
the  USC/Information  Sciences  Institute.  The 


project's  goal  is  to  provide  time-shared  user 
access  to  a  writable  control  memory  micro¬ 
processor  as  a  service  in  a  multiprogram- 
med  environment.  This  service  is  intended 
to  be  used  in-house,  as  well  as  nationally 
over  the  ARPANET. 

The  MLP-900  is  connected  to  a  PDP-10 
processor  through  the  I/O  buss  (event  chan¬ 
nel)  and  the  memory  buss  (data  channel) 
The  data  bandwidth  ib  100MHz.  The  MLP- 
900  is  strictly  a  slave  processor.  The  PDP- 
10  TENEX  time-sharing  system  does  all  tar¬ 
get  memory  allocation  and  I/O  for  the  MLP- 
900.  The  intention  is  for  the  MLP-900  to 
act  as  a  user-specified  time-shared  execu¬ 
tion  engine  for  users  on  the  PDP-10 

The  MLP-900 

GPM  has  been  designed  around  the  ac¬ 
tual  MLP-900  hardware.  This  has  been 
done  for  efficiency  and  convenience.  First, 
language  forms  ill-suited  for  the  MLP-900 
hardware  were  not  provided,  for  efficiency 
Second,  special  language  forms  were  cre¬ 
ated  io  deal  with  the  novel  aspects  of  the 
MLP-900,  for  convenience  For  this  reason, 
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a  brief  description  of  the  MLP-900  is  neces¬ 
sary  for  background  to  understand  GPM. 

The  MLP-900  \4,5,6\  is  a  vertical  word 
microprocessor  which  runs  synchronously 
with  a  5MHz  clock.  It  is  characterized  by 
two  parallel  computing  engines  called  the 
Operating  Engine  (OE)  and  the  Control 
Engine  (CE).  The  OE  performs  arithmetic 
operations  and  the  CE  performs  control  op¬ 
erations.  The  OE  contains  32  36-bit  gen¬ 
eral-purpose  registers  (R0-R31)  for  oper¬ 
ands  and  16  3 6 -bit  mask  registers  (MO- 
MI  5)  to  specify  operand  fields.  The  CE  con  ¬ 
tains  256  L'.tte  flip/flops  (F0-F255)  orga¬ 
nized  in  16  8-bit  registers  (CE0-CE1  5).  The 
CE  also  contains  a  1  6  word  hardware  stack 
aid  16  8 -bit  pointer  registers  (P0-P15). 
Thc  writable  control  memory  contains  4K 
words.  Additionally,  there  is  a  1 K  36-bit 
auxiliary  memory. 

The  OE  and  CE  will  execute  in  parallel  if, 
and  only  if,  a  CE  instruction  follows  an  OE 
instruction  during  the  execution.  Program¬ 
mer  consideration  of  this  feature  usually  is 
not  requireo  However,  if  a  program  is  exe¬ 
cuted  entirely  as  OE-CE  instruction  pairs, 
the  effective  machine  speed  is  doubled. 

The  MLP-900  also  has  features  to  sup¬ 
port  a  microvisor,  which  will  swap  users  and 
handle  I/O  requests  to  TENEX.  These  fea¬ 
tures  include  microvisor  mode,  privileged 
instructions,  control  memory  protection,  and 
processor  state  protection  Additionally,  the 
MLP-900  has  an  address  transformation 
box  to  allow  demand  paging  of  the  target 
program  and  data  in  cooperation  with  the 
TENEX  time-sharing  system. 


GPM  Goals 

The  primary  goal  of  the  GPM  design  was 
to  produce  a  higher-level  language  which 
did  not  preclude  any  coding  options  In 
particular,  as  GPM  was  to  bo  the  primary 
language  for  the  MLP-900,  every  control 
memory  code  had  to  be  possible  as  lan¬ 
guage  output.  The  language  had  to  be  ame¬ 
nable  to  diagnositc  programmers,  applica¬ 
tion  programmers,  and  researchers.  This 
was  accomplished  by  combining  the  appro¬ 
priate  features  of  assembly  code  with  the 
complimentary  higher-level  language  fea¬ 
tures. 

Some  GPM  statements  look  very  much 
like  assembly  ianguage.  These  statements 
correspond  to  the  I/O  instruction.  The 
higher-level  statements  fall  into  four  catego¬ 
ries  of  interest: 

1 .  syntactic  block  structure; 

2.  hardware  generalization; 

3.  multi-instruction  statements; 

4.  expressions. 

Each  of  these  will  be  discussed  in  detail 
below. 

Syntactic  Block  Structure 

The  low-level  constraints  in  the  GPM  de¬ 
sign  precluded  the  implementation  of  any 
dynamic  storage  allocation,  or  even  of  an 
operand  stack.  As  a  result,  the  block  struc¬ 
turing  in  GPM  may  be  considered  to  be  a 
compile-time  artifact.  None  the  less,  by  us¬ 
ing  the  block  structure  syntax  in  a  most 
rudimentary  way,  the  resulting  language 
has  been  rendered  more  tractable  and  com¬ 
prehensible. 
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The  block  structure  syntax  is  the  standard 
BEGIN  declarations;  body;  END.  This  syntax 
is  used  at  compile-time  to  specify  scope. 
This  is  used  both  for  data  names  (all  labels 
are  global)  and  control  statements.  Blocks 
may  be  named,  and  several  blocks  may  be 
closed  with  a  single  named  END. 

Names 

Every  memory  cell  in  the  MLP-900  is 
explicitly  named  with  a  reserved  word  in 
GPM  (e  g  general  register  3  is  R3  and 
pointer  register  5  is  P5).  These  names  are 
not  necessarily  mnemonic,  so  the  user  may 
rename  any  memory  cell  at  the  top  of  a 
block. 

Any  synonym  defined  at  the  start  of  a 
block  is  undefined  at  the  end  of  the  block. 
This  allows  procedures  to  give  mnemonic 
names  to  parameters  and  temporary  regis¬ 
ters.  Additionally,  the  practice  of  "declar¬ 
ing"  registers  at  the  top  of  a  block  renders 
the  blocks  scope  instantly  apparent. 

This  block-structured  synonym  facility,  if 
exploited  properly,  can  produce  more  read¬ 
able  programs.  The  user  mr  y  also  rename 
any  reserved  word  in  GPM  using  this  same 
facility. 

Control  Statements 

The  block  structure  syntax  is  used  to  de¬ 
fine  the  scope  of  IF  statements  and  DO 
statements.  The  DO  statement  heads  a  block 
which  will  be  iterated  upon  indefinitely.  The 
method  of  exiting  a  DO  block  is  the  BREAK 
statement. 

The  BREAK  statement  semantics  are  de¬ 
fined  in  terms  of  the  lexical  block  structure. 


A  BREAK  statement  transfers  control  out  of 
the  lexical  block  named  by  the  statement.  If 
no  name  is  supplied,  the  current  block  is 
assumed. 

The  above  examples  of  applications  of 
block  structure  syntax  demonstrate  how  the 
concept  can  be  useful  in  a  semantically 
simple  language.  One  could  even  restate 
the  GPM  design  goal  design  a  language 
which  is  syntactically  rich  and  semantically 
poor. 

Hardware  Generalization 

One  of  the  more  classical  functions  of  a 
programming  language  is  to  provide  a  com¬ 
plete  set  of  functions,  where  the  hardware 
may  not.  For  instance,  on  a  computer  with 
only  a  jump  on  less  than  zero,  the  program¬ 
ming  language  would  provide  all  eight  pos¬ 
sible  jumps  relative  to  zero. 

GPM  attempts  to  do  this  in  all  cases 
where  it  is  possible,  without  violating  the 
design  constraints.  Two  examples  will  illus¬ 
trate  this  idea. 

Example  -  GOTO  destinations 

The  following  are  all  hardware  MLP-900 
instructions' 

GOTO  100;  absolute  jump 

GOTO  +  10;  relative  jump 

GOTO  5  (PO);  indexed  absolute 

GOTO  +  1  (PO);  indexed  relative 

However,  the  statement  GOTO  +  3  <P0> 
is  not  an  MLP-900  instruction,  as  the  hard¬ 
ware  only  supports  indexed  relative  jumps 
with  a  +  1  relative  offset.  However,  the 
above  statement  is  legal  in  GPM  and  the 
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compiler  changes  the  relative  offset  to  the 
appropriate  absolute  address. 

Example  -  Ct  assignments 
This  example  will  require  a  further  de¬ 
scription  of  the  vagaries  of  the  MLP-900. 
As  mentioned  above,  the  CE  contains  256 
state  flip/flops  (FO  F255)  organized  into  1 6 
8  bit  registers  (CE0-CE15)  This  example 
discusses  the  instructions  to  transfer  data 
between  these  en.ities.  The  following  are  all 
hardware  MLP-90C  instructions. 

CEO  -  CF1  (77' 

Transfer  the  contents  of  register  1  to  regis¬ 
ter  0  for  all  bits  set  in  the  octal  mask  (77  in 
this  case). 

CEO  -  NOT  CE1  (77)  ; 

This  is  the  same  as  the  previous  instruction, 
except  register  1  is  complemented  first. 

CEO  -  CE1  [77]  ; 

This  is  the  same  as  the  first  instruction, 
except  all  bits  not  set  in  the  mask  are 
cleared  in  register  0 

The  legal  GPM  statement 

CEO  -  NOT  CE1  [77]  ; 
will  compile  into’" 

CEO  -  NOT  CE  1  (77)  ; 

CEO  -  CEO  [77]  ; 

This  type  of  language  feature  allows  the 
programmer  to  ignore  some  of  the  intrica¬ 
cies  of  the  hardware.  However,  if  a  GPM 
programmer  wishes,  he/she  may  stick  to 
the  GPM  subset  which  corresponds  to  the 
hardware  MLP-900  instructions. 

*  As  GPM  IS  ,he  primai '  MLP-900  language  n  compiles  into  the 
subset  ol  itself  which  cotresponcis  to  actual  hatdwaie  insttuctions 


Multi-instruction  Statements 

Some  GPM  statements  will  always  com¬ 
pile  int,  several  hardware  MLP-900  in¬ 
structions.  These  are  common  fuctions  with 
which  the  user  should  not  have  to  concern 
himself/herself. 

Example  -  Case  statement 
The  GPM  statement 

SWITCHON  PO  INTO 

will  produce  an  indexed  jump  into  a  transfer 
table  specified  by  CASEs  specified  in  the 
block  which  the  SWITCHON  heads.  This 
requires  the  automatic  generation  of  the 
transfer  table  somewhere  in  control  memory. 
Example  -  Inter-engine  assignments 
In  order  to  transfer  data  from  the  operat¬ 
ing  engine  to  the  control  engine,  the  ex¬ 
change  buss  (XBUS)  is  used.  This  requires 
an  OE-CE  instruction  pair  to  be  executed  in 
parallel.  Therefore,  all  inter-engine  assign¬ 
ments  require  the  generation  of  two  instruc¬ 
tions. 

The  GPM  Statement 
CEO  -  RO  ; 
will  compile  into 
XBUS  -  RO  ; 

CEO  -  XBUS  ; 

However,  as  both  instructions  are  to  be 
executed  in  parallel,  the  GPM  statement 

RO  -  CEO  ; 

will  compile  into  the  non-intuitive 
RO  -  XBUS  ; 

XBUS  -  PO  ; 
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These  multi-instruction  generating  state¬ 
ments  make  programs  shorter  and  thus  eas¬ 
ier  to  read.  The  information  not  explicitly 
stated  is  essentially  irrelevant  in  the  latter 
example,  and  redundant  in  the  former. 
Thus,  brevity  is  achieved  without  the  intro¬ 
duction  of  obscurity. 

Expressions 

Expressions  are  so  common  in  higher- 
level  languages,  it  might  seem  out  of  place 
to  devote  an  entire  section  to  them  here. 
However,  the  constraints  on  the  GPM  de¬ 
sign  complicates  the  compilation  of  expres¬ 
sions.  GPM  is  not  allowed  to  make  any 
imp'icit  changes  to  the  machine  state  at 
runtime.  This  precludes  the  introduction  of 
temporaries  to  evaluate  expressions.  Two 
brief  examples  will  demonstrate  how  ex¬ 
pressions  are  to  be  handled. 

Example  -  Arithmetic  expressions 

The  GPM  statement 

RO  -  RO  AND  R1  +  R2  , 
will  compile  into 

RO  -  RO  AND  R1  ; 

RO  -  RO  +  R2  ; 

However  the  GPM  statement 

RO  -  RO  AND  (  R1  +  R2  )  ; 

will  not  compile,  for  lack  of  a  temporary  for 
(Rl  +  R2). 

Example  -  Boolean  expressions 

The  GPM  statement 


FO  -  (FI  and  F2)  or  (  F3  AND  F4) 
will  compile  into 

IF  FI  AND  F2  THEN  GOTO  +3  , 

IF  F3  AND  F4  THEN  GOTO  +2  , 

IF  NOT  (FO  -  FALSE  )  THEN 

GOTO  +  2  ; 

FO  -  TRUE  ; 

Boolean  expressions  will  always  compile  as 
the  program  counter  can  be  used  as  a  tem¬ 
porary  boolean  value. 

The  exp,ession  evaluation  in  GPM  leaves 
much  to  be  desired,  but  it  was  felt  that 
when  the  expressions  worked,  they  were  so 
superior  to  the  assembly  code  alternative 
that  they  would  be  included  in  spite  of 
themselves. 

Conclusion 

This  paper  has  reported  on  some  ideas  to 
make  microprogramming  more  agreeable  in 
light  of  the  previous  experience  of  the  com¬ 
puter  community  with  conventional  com¬ 
puters  The  opinion  stated  here  is  that  a 
hybrid  language  is  necessary  for  the  task. 
This  paper  described  several  of  the  problems 
and  solutions  associated  with  this  approach. 

It  appears  that  with  careful  consideration 
to  the  actual  processor  in  question,  it  is 
possible  to  create  a  passive  higher-level  lan¬ 
guage,  which  allows  total  user  control, 
while,  at  the  same  time,  encouraging  read¬ 
able  programs  and  allowing  easy  language 
usage. 
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